Synthesis of Hierarchical Systems from a Library

Synthesis is the automated construction of a system from its specification. The basic idea is simple and appealing: instead of developing a system and verifying that it is correct w.r.t. its specification, we use instead an automated procedure that, given a specification, constructs a system that is correct by construction. The first formulation of synthesis goes back to Church [5]; the modern approach to this problem was initiated by Pnueli and Rosner who introduced linear temporal logic (LTL) synthesis [14], later extended to handle branching-time specifications, such as μ-calculus [7]. In spite of the rich theory developed for system synthesis in the last two decades, little of this theory has been reduced to practice. In fact, the main approaches to tackle synthesis in practice are either to use heuristics (e.g., [9]) or to restrict to simple specifications (e.g., [13]). Some people argue that this is because the synthesis problem is very expensive compared to model-checking [10]. There is, however, something misleading in this perception: while the complexity of synthesis is given with respect to the specification only, the complexity of model-checking is given also with respect to a program, which can be very large. A common thread in almost all of the works concerning synthesis is the assumption that the system is to be built “from scratch”. Obviously, real-world systems are rarely constructed this way, but rather by utilizing many preexisting reusable components, i.e., a library. Using standard preexisting components is sometimes unavoidable (for example, access to hardware resources is usually under the control of the operating system, which must be “reused”), and many times has other benefits (apart from saving time and effort, which may seem to be less of a problem in a setting of automatic as opposed to manual synthesis), such as maintaining a common code base, and abstracting away low level details that are already handled by the preexisting components. Another important reason for the limited use of formal synthesis in practice is the fact that synthesized systems are usually monolithic and look very unnatural from the system designer’s point of view. Indeed, in classical synthesis algorithms, one usually creates a “flat” system, i.e., a system in which sub-systems may be repeated many times. On the contrary, real-life software and hardware systems are hierarchical (or even recursive) and repeated sub-systems (such as subroutines) are described only once. While hierarchical systems may be exponentially more succinct than flat ones, it has been shown that the cost of solving questions about them (like model-checking) are in many cases not exponentially higher [3, 4, 8]. Hierarchical systems can also be seen as a special case of recursive systems [1, 2], where the nesting of calls to sub-systems is bounded. However, having no bound on the nesting of calls gives rise to infinite-state systems, and this results in a higher complexity. In this work we provide a uniform algorithm, for different temporal logics, for the synthesis of hierarchical systems (or, equivalently, transducers) from a library of hierarchical systems, which mimics the “bottom-up” approach to system design, where one builds a system by constructing new modules based on previously constructed ones1. More specifically, the synthesis process starts by providing the algorithm with a library of available hierarchical components (as well as atomic ones). Then, the system designer provides a specification formula φ of the desired hierarchical component, which is then automatically synthesized using the currently available components as possible subcomponents. We show that while hierarchical systems may be exponentially smaller than flat ones, the problem of synthesizing a hierarchical system from a library of existing hierarchical systems is EXPTIME-complete for μ-calculus, and 2EXPTIME-complete for LTL. Thus, this problem is not harder than the classical synthesis problem of flat systems “from scratch”. Furthermore, we show